FPGA Based AES Encryption Processor

ECE 253 Embedded Systems Design

Brett Brotherton

Nick Callegari

Progress Report

Background

             Network security is becoming an ever so vital part of wireless communication in embedded systems.  As PDA and other hand held devices becoming more and more sophisticated, incorporating wireless protocols and allowing more functionality for users, it is inevitable that more private and important data is transferred across these protocols.  PDAs today are able to connect to wifi, IEEE 802.11 protocols connecting users to the internet, webpages, email, and even bank account information via bank websites.  

             With this need of network security for embedded systems also comes with a lot of constraints to make it a viable solution to incorporate that security system into the embedded system.  Although the cost of many hand held devices are thought to be expensive, it is always a vital constraint for the security system to be low cost.  Because even if your PDA costs a couple hundred dollars, it also incorporates a lot of other components that create the functionality, and the security would only be a small portion.  Another constraint is that it need to be small, in all reality this needs to fit into an embedded system such as a PDA, which also incorporates a CPU, memory, screen, some type of input device, and must still be small enough to fit into the palm of your hand.  In addition, of course the third constraint is that the security must be secure enough that people are deterred and prevented from breaking it, because what good is a security system if anyone can break it?

             Given that there is a need for network security for embedded systems, and the security device must be small, inexpensive, and secure, an FPGA chip was a good choice to incorporate this system on.  Given that an FPGA can be small in size, they are rather inexpensive, and given that they are able to be reprogrammed to incorporate any new encryption advances, it allows for a secure solution as well.  With an FPGA chosen as a strong platform to incorporate our design, a necessary protocol had to be chosen for which to encrypt our data.  After some research we found that The National Institute of Standards and Technology (NIST) selected the Rijndael algorithm as a new Advanced Encryption Standard (AES) in 2001.  This standard was first developed for secure data encryption/decryption for high-end applications.  With the advancement in speed and size for FPGA chips since 2001, and the outlook of other research colleagues using the protocol for similar research, we thought it would be a sufficient encryption protocol to incorporate in our design. 

              With the design being incorporated into a programmable gate array, it leaves a significant room for advancement through testing and implementation.  There is a large amount of improvement available after the foundation of the AES encryption protocol is incorporated into the chip.  Because it has future implementation in an embedded system, and power consumption is always an issue, there is room to modify the AES algorithm to make it more efficient and less power consuming.  There is always room for improvement in the security itself as well, such as isolating the encryption so there is no way for an attacker to obtain a key.  It is not only important to make sure the core is secure, but also the shared memory as well, because it too could contain sensitive information such as keys and unencrypted data.

      Our main goal of our project is to implement an AES encryption core on an FPGA, and use it as a solid platform to demonstrate our various security techniques.  With the increasing use of FPGAs especially in security related functions as described above it is important to develop a set of tools and standards that we can use to ensure make them more secure. Once we have completed the basic functioning system we can try to incorporate more features into it, giving us a valuable platform for the testing and demonstration of the security techniques and standards which we develop.  First, we would like to partition the design using “motes,” and then analyze it with our route tracing tool.  This however may not be possible since Jbits does not currently support Virtex-4 FPGAs and it looks like there is little chance of future support.  This design is a good example of a system that we would want to use motes and drawbridges.  We are dealing with encryption which we want to ensure is isolated so that there is no way for an attacker to obtain the key(s) or unencrypted data.  We are also dealing with a third party core which we have downloaded from open cores.  This is a great example of a system where you would want to isolate a core with a moat in this case we would want to isolate the AES encryption core.  Another feature we would like to incorporate into our design is TDMA secure bus architecture.  Our design would serve as a good platform for developing the protocol for this architecture.  It would allow for performance testing to see if this architecture can perform fast enough and analyze the tradeoffs of the architecture. 

One interesting thing about our design is that the microprocessor and encryption core communicate solely through a shared memory block.  Since this memory block is connected to the microprocessors shared bus we would like to be able to ensure that access to it can be regulated since it will contain sensitive information such as keys and unencrypted data.  Ted Huffmire’s memory reference monitor is one such way this could be accomplished.  It could allow us to control the what portions of the shared memory each device on the bus could read and write to.  We could even completely disable reading of the keys and unencrypted data by everyone except the AES core.  Combining the reference monitor with the secure bus would allow for a very secure communication protocol in which covert channels would be greatly reduced or eliminated.  Our platform will serve as a basis for developing and working out the quirks of these different protocols.  They will also allow us to analyze how they all work together and see what sort of effect the really have on performance in a modern FPGA based system.  

            We believe that given the background and issue at hand, our goal will provide a fast, efficient, and secure decryption/encryption of data.  Not only does it prove as a great project for this course, but it is also very scalable for future research and development, for incorporation into real life concepts. 

 Approach

             This project has two distinct parts to it, the software design part and the hardware design part.  The hardware consists mostly of off the shelf IP cores, with the exception of the controller that interfaces between the processor and the AES core.  The software must be able to handle the input from the RS232 and then transfer this input to the appropriate locations in the memory, and set up the AES core to perform the correct operation.  We have divided up the project into 4 main parts as follows:

1        Communication Protocol for AES and processor core.

2        Design of controller to implement communication protocol with processor and control the operation of the AES core with little processor intervention

3        Design of protocol for transfering data and specifying what to do with the data from computer to system over RS232.

4        Design of software for the Microblaze processor to bridge the communication between the AES core and RS232 and handle other system functions like user IO. 

            The protocol design mostly takes place on paper and tries to keep the design as modular and general as possible while maintaining simplicity for efficiency and ease of implementation.  Design of the controller is done using a combination of Verilog and VHDL.  Modelsim is used for simulation and testing and ISE is used to synthesize the design to hardware.  Then we use the Xilinx Platform Studio (XPS) to combine the custom hardware with off the shelf IP cores to make a complete system.  The software design is also done in XPS and all software is programmed in C.  The software is used to first test all the hardware peripherals and then eventually to finish the design and serve as the bridge between the peripherals.  Most drivers are provided by the XPS and the software is compiled into an executable that can then be downloaded to the board using XPS.  Here is a simplified design flow diagram:

Progress

             The first thing that we did for this project was to do a survey of different AES modules that we could obtain from the Internet to determine what would be best for our application.  After choosing a suitable controller we next concentrated on the protocol.  It was decided to communicate with the processor and control the device through the use of a shared memory.  The controller would be given a go signal, control word, start address of data and keys, end address, and write address and would perform the necessary operations.  It has and encrypt and decrypt mode and a single or multiple key mode (single key mode has one 128b key for multiple 128b blocks of data and multiple key mode has a separate 128b key for each 128b block of data).  From this protocol we then moved onto the hardware design.  First we constructed a state machine and a datapath.  Then the design was implemented and tested in Verilog.  Below is the FSM for the design. 

            Next we combined this with the other necessary components to create the system in an XPS project and synthesized the design into a bitstream.  With this step we went onto software design.  We are currently working on testing the design on the chip with a simple hard coded values and are running into problems.  So right now we are trying to debug our hardware module and make sure it is functioning correctly. 

 Future Work

             We still have quite a bit of work we would like to get done.  Once the issues are resolved we must come up with our protocol for issuing commands and data over the RS232 and then we must finish the software design to implement this protocol.  After that is done we can get to the interesting part of the project which is testing different security ideas in an actual design.  First we would like to partition the design into moats and see the affect this has on the design size and performance.  Time permitting we would also like to try and incorporate Ted Huffmire's memory reference monitor.  Getting a working version of the TDMA bus architecture will most likely take more time than we have but will definitely be a project for the future. 

Home        Project Proposal        Links         Literature Survey        Progress Report